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ABSTRACT 



A client workstation generates a network request for an 
initial program load. The request is serviced by a server 
which preferably includes in the reply to the client the 
addresses of an authentication server (AS), client, and a 
secure initial program load server (SECIPL). The client 
then requests an SECIPL service ticket from the AS, 
also sending a common identifier known to the AS and 
the client, preferably stored in the client ROM. This 
identifier is utilized by the AS to validate the ticket 
request as originating from a bona fide client, where- 
upon the ticket is provided by the AS to the client, the 
SECIPL service ticket is then presented by the client to 
the SECIPL server which then authenticates that the 
ticket is bona fide and was received by the client from 
the AS. The SECIPL then provides a secure kernel to 
the client, either encrypted with a key known to the 
SECIPL and client, or otherwise secured by a crypto- 
graphic checksum utilizing a key known to the client 
and the SECIPL. In this manner, the client workstation 
is thereby assured that an authenticated boot image has 
been received through potentially non-secure commu- 
nication links, 

24 Cairns, 3 Drawing Sheets 
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SYSTEM AND METHOD FOR SECURE INmAL 
PROGRAM LOAD FOR DISKLESS 
WORKSTATIONS 

5 

FIELD OF THE INVENTION 

This invention relates to computer networks in gen- 
eral and, more particularly, concerns systems and meth- 
ods for ensuring a secure boot for a diskless worksta- 
tion. 10 

BACKGROUND OF THE INVENTION 

Computer networks are quite prevalent in the art 
now which provide for one or more server machines 
interconnected in a network fashion to multiple client 
machines generally of lesser capability. There are nu- 
merous benefits to this arrangement. For example un- 
necessary replication of more expensive hardware at the 
clients is avoided which might otherwise be shared by 
multiple clients if located at a central repository. 20 

In such networks, it is common to provide the client 
machines in the form of medialess or diskless worksta- 
tions. These machines have no substantial (and gener- 
ally more expensive) non-volatile mass storage devices 
such as DASD or the like. Rather, they rely upon mass 25 
storage devices such as at servers at other locations in 
the network to store the necessary code and data which 
must be available to the client machines to perform their 
functions. In such arrangements, it is conventional for 
the server(s) to deliver the code and data over the net- 30 
work connection to the particular cUent at appropriate 
times. In this manner, the client need only have present 
in its real memory at any given time only the informa- 
tion stored in the mass storage devices at the server(s) 
necessary to perform a function at that time. The need 35 
is thereby avoided of having mass storage devices at 
each client containing information which remains in an 
unused state for long periods of time and which adds to 
the cost of the network. 

Representative such client-server systems may be 40 
seen described in U.S. Pat. No. 5,056,140 entitled 
"Communication Security Accessing System and Pro- 
cess" and U.S. Pat. No. 4,958,278 entitled "Method for 
Loading Data or Program to a Plurality of Terminal 
Stations", for example. 45 

Several problems have come about as a result of the 
growth of these computer network systems. Not the 
least of these is the serious problem of unauthorized 
access to the systems which has been reported with 
alarming increased frequency. With the proliferation of 50 
large multi-user computer systems with enormous 
banks of extremely valuable data, techniques were 
highly sought for enhancing the security of these net- 
works. 

Accordingly, numerous schemes have developed 55 
over the years including encryption, passwords, physi- 
cal security devices such as keyed switches, and so forth 
in an effort to deter the rising rates of unauthorized 
access. Several subtle security exposures arise from the 
characteristics of the diskless workstation in seeking to 60 
secure the previously described network systems which 
employ diskless workstations. As but one example, in 
order for such a workstation to become operative upon 
power up, it is necessary for the workstation to obtain 
the kernel operating system code from somewhere else 65 
in the network. This is because the operating system is 
not resident at the workstation itself (for reasons previ- 
ously described that the non-volatile storage necessary 
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to store the operating system at the workstation is unde- 
sirable and cost-prohibitive.) One problem with this, 
however, is that the industry standard boot protocol 
does not provide for certification of this kernel code 
delivered from the network to the booting diskless 
workstation in any way. 

The delivery of non-certified boot code to a worksta- 
tion upon booting is fraught with numerous problems 
which have beset the industry, particularly in the more 
security-sensitive areas in which computer networks 
have been established. As but one example, one of the 
computers in the network could be configured to pro- 
vide a kernel to a diskless system when it boots. It may 
be assumed, for purposes of illustration, that this kernel- 
providing system may be faster at providing such kernel 
code than the "officially" designated kernel source 
machine for the network. In such a case, upon booting 
of the diskless workstation, the non-certified kernel 
from the computer will be loaded by the workstations 
which then, in response, might very typically be asked 
to supply a password. Upon the password being pro- 
vided by the operator at the workstation, this password 
would be received by the computer providing the 
bogus boot kernel code requested by the workstation. 
Later, the unauthorized individual, who has thereby 
surreptitiously obtained the valid password from the 
workstation operator, could sign onto the network sys- 
tem, utilize the thus-obtained valid password, and unau- 
thorizedly enter the entire computer network. 

In an effort to solve the foregoing problems, numer- 
ous solutions were attempted resulting in customer 
requirements for diskless stations, networks and modifi- 
cations which were not appropriate or cost-effective for 
systems not requiring such security. This resulted in 
manufacttiring expenses and costs associated with pro- 
viding two types of systems. 

Accordingly, systems and methods were needed 
which could provide assurances that a diskless worksta- 
tion was obtaining a certified kernel upon booting, and 
which could fmther ensure the kernel server that the 
workstation machine requesting the kernel was an au- 
thorized workstation. 

It was accordingly an object of the invention to pro- 
vide an improved boot architecture. 

Yet another object of the invention is thus to provide 
an improved communication security system for disk- 
less workstations which rejects connection to an unau- 
thorized user terminal. 

Still another object was to provide for a boot archi- 
tecture for secure initial program load (IPL) for diskless 
workstations which nevertheless provided the ability to 
offer one standard diskless station with only minimal 
modifications being required for the addition of a secure 
IPL feature. 

These and other objects and features are provided by 
the invention, a fuller understanding of which may be 
obtained with reference to the following description 
taken in connection with the accompanying drawings, 
wherein: 

SUMMARY OF THE INVENTION 

A cUent workstation generates a network request for 
initial load information. The request is serviced by a 
server which preferably includes in the reply to the 
client the addresses of an authentication server (AS), 
client, and a secure initial program load server (SE- 
CIPL). Additionally, the reply will typically include 
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the client realm, client principal name and time of day, contain more limited storage 20 for storing the neccs- 
although the latter two may optionally be provided sary IPL and kernel code 18 which is downloaded 
other servers whose names are provided in the bootp through the server 10 and the LAN 14 when the partic- 
response or otherwise available to the client in hard- ular workstation is booted. This storage 20 is typically 
ware. The client then requests an SECIPL service 5 in the form of volatile random access memory which is 
ticket from the AS, also sending a common identifier relatively inexpensive. It however has the unfortunate 
known to the AS and the client, preferably stored in the characteristic that upon power dovm the data stored 
client ROM. This identifier may be the principal name therein is destroyed, thus requiring repeated download 
of the SECIPL utilized by the AS to validate the ticket of the code 18 from the server 10 upon each such in- 
request as originating from a bona fide client. The ticket 10 stance of booting of a workstation. The workstations 
is then provided by the AS to the client after the AS may, in some mstances however, have non-volatiJe 
authenticates the client by means of checking the com- storage and the invention is thus not intended to be 
mon identifier. The SECIPL service ticket thereby limited only to diskless workstations, 
received by the client from the AS is then presented by It will be noted in passing that these workstations also 
the client to the SECIPL server. The SECIPL server 15 typically contain a small amount of non- volatile storage 
then authenticates that the ticket provided by the client capacity normally in the form of read only memory 
to the SECIPL is bona fide and was received by the (ROM). This ROM contains the essential code perform- 
client from the AS, in that the SECIPL has knowledge ing the very limited function of initiating the download 
of the content of an authentic ticket originating from procedure of the more extensive boot IPL and kernel 
the AS. The SECIPL then provides a secure kernel to 20 operating system code which will thereafter be used by 
the client, either encrypted with a key known to the the particular workstation in performing its normal 
SECIPL and client, or otherwise secured by a crypto- functions. 

graphic checksum utilizing a key known to the client Turning now to the diagram of the network shown in 
and the SECIPL. In this manner, the client workstation FIG. 2. the features of the present invention will now be 
is thereby assured that an authenticated boot image has 25 described providing for delivery of a secure initial pro- 
been received through potentially non-secure commu- gram load of this code 18 for such workstations. First 
nication. the components of FIG. 2 and a high level explanation 

IN THE DRAWINGS functions will be described with reference to 

FIG. 2 followed by a detailed description of the se- 
FIG. 1 is a functional diagram of a conventional com- 30 quence of operation of the invention with reference to 
puter client-server network utilizing diskless worksta- the flow diagram of FIG. 3. 

^^ons; There is shown in FIG. 2 a plurality of client work- 

FIG. 2 is a more detailed functional block diagram of stations 20 similar to the workstations 12A-12N of FIG. 

a networking system of FIG. 1 utilizing the secure IPL 1. Additionally, the system of FIG. 2 typically includes 

process in accordance with the invention; and 35 a secure IPL server 28, which serves the purpose of 

FIGS. 3A and 3B is a flow diagram representing the providing the program images required for IPL by the 

sequence of process steps in accordance with the inven- client workstations 20. 

tion providing a secure IPL for diskless workstations in Additionally, the system of FIG. 2 will typically 
a computer networking environment. include an authentication server such as Kerberos 

DETAILED DESCRIPTION OF THE ^ server 24, which serves the purpose of ensuring that 

PREFERRED EMBODIMENT upon initial contact with the AS, each workstation cli- 

ent 2U IS venned to be genume and further responsible 

Referring first to FIG. 1, a conventional computer for providing authentication keys for continued opera- 
network is shown typically comprised of a server sta- tion. Although the embodiment depicted employs a 
tion 10 ("server'*), and a plurality of terminal stations or 45 Kerberos authentication system well known in the art, 
workstations also known as ''clients" 12A-12N inter- the invention is not intended to be limited to such a 
connected by means of a local area network or LAN 14. particular implementation of a security system. 
The server station 10 includes a mass storage unit 16 Also, the system of FIG. 2 will desirably include a 
known as a direct access storage device PASD). bootp server 44 which serves the function of responding 

One of the desirable characteristics of the client- 50 to client bootp requests to provide information which 
server type networks shown in FIG, 1 stems from the allows the clients to continue with the boot process, 
fact that in such networks it may be conmion to have The foregoing generally described functional elements 
large numbers of such workstations distributed of the system FIG. 2, it will be appreciated, may be 
throughout a work environment. Accordingly it is implemented on multiple physical machines or on a 
highly desirable to keep the cost of such workstations 55 single machine as the application dictates, 
low and avoid unnecessary duplication of hardware The workstations 20 function through a LAN 21 
which might better and more efficiently be hnple- functionally represented by the arrows in connection 
mented at a central location such as at the server. One with various servers to be hereinafter described and 
such opportunity arises from the fact that there is com- mass storage 23 broadly in a manner similar to that of 
mon code and data which typically must be utilized by 60 FIG. 1. However, with respect to the system and 
all of the workstations 12A-12N upon initial boot up method of the invention, the client workstations 20 
procedures as well as common operating system code access some minimal information utilized to implement 
enabling the workstations to perform their normal work the desired authentication service of the invention 
functions. whereby the kernel and client boot sequence may 

This initial program load (IPL) and kernel code 18 65 thereby be certified or authenticated. This information 
may thus advantageously be stored in the DASD 16 and shown in FIGS. 3A and 38 includes a first service key 
then accessed as necessary in a boot sequence by the 22 for each workstation to be hereinafter described 
workstations 12A-12N. These workstations will in fact known only to the client workstations 20 and the Ker- 
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beros Authentication Server (AS) 24. Further such 
information includes the principal name 26 of the secure 
kernel IPL service (SECIPL) 28 and the client's 
REALM name 30. A realm name is a concept of secu- 
rity systems whereby a client is assigned a realm name 5 
utilized by a security server 24, The client to instruct 
the client 20 as to which security server 24 the client is 
to communicate with to validate information. Still fur- 
ther such infonnation desirably includes the current 
time of day 34 within a REALM-specific skew value 10 
which may be provided by a bootp server 44, the princi- 
pal name 32 of the client 20 (also provided by the bootp 
server 44), the IP address 36 of the client 20, the IP 
address 38 of the authentication server 24, and the IP 
address 40 of the SECIPL server 28. 15 

It is desirable for the ROM 42 of each client 20 to 
contain the previously noted principal name 26 of the 
SECIPL server or service 28. The client 20 as previ- 
ously noted is also responsible for knowing the secret 
first key 22 to be hereinafter described. The BOOTP 20 
server 44 is provided which may provide the aforemen- 
tioned principal name of the client itself, 32, and the 
current time of day 34. The BOOTP server 44 will 
desirably also provide the just-described client's realm 
name 30, and the IP addresses 36-40 of the clients, the 25 
AS server and the SECIPL, respectively. 

The confidential first key 22 is preferably only known 
by the client workstation's 20 and the AS server 24 (as 
well as, of course, a system network administrator, 
security personnel, or the like, etc.). Regarding imple- 30 
mentation of the key 22 on the client side of the net- 
work, in one implementation an external security device 
46 such as a keyed lock may be physically attached to 
the client workstation's 20 in order to provide the key 
22. It will be noted that the key 22 utilized by the client 35 
workstation's 20 preferably will not be used anywhere 
else. Such a key 22 is to be distinguished from a key 
typically utilized by an individual signing onto a work- 
station 20 which is utilized to validate the user to the 
server 24. It will further be noted that the key 22 in the 40 
preferred implementation will be utilized only once, 
whereby such a key 22 will be employed to request 
from the AS server 24 a ticket 48 to the SECIPL ser- 
vice 28. Conventionally the AS server 24 would nor- 
mally provide a ticket to a Ticket Granting Service 45 
(TGS) which itself performs the action function of pro- 
vidmg a key 22. 

As noted before, the principal name 26 of the SE- 
CIPL service 28 in a preferred embodiment is to be 
hard-coded into the ROM 42 of each client workstation 50 
20, This is to prevent an attack on the security of the 
network described hereinbefore in the Background of 
the Invention wherein an export of a valid service may 
create a counterfeit BOOTP server which could re- 
spond more quickly than the bonafide real BOOTP 55 
service 44. This counterfeit BOOTP server could 
thereby present the IP address and service name of a 
counterfeit IPL server. The client 20 in such an attempt 
at a security breach, would authenticate normally, and 
the resulting bits received from the counterfeit SECIPL 60 
server could thereby be utilized to attack the security of 
the network effecting a serious security breach. 

Two items of optional infonnation in the implementa- 
tion being described with reference to FIG. 3 presented 
by the BOOTP server 44 to the client 20 must be de- 65 
rived by the workstation 20 if they are not provided in 
the BOOTP response. The principal name 32 of the 
client 20 may be derived by querying a local name- 
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server, where the IP address of the nameserver was 
provided in the BOOTP response. The current time of 
day 34, in like manner may be acquired by querying a 
local time server where the IP address of the timeserver 
could be provided also in the BOOTP response. Both or 
either of these pieces of information may be cached 
locally or derived in some implementation-specific way 
as desired. The other four items of information (namely 
the IP addresses 36-40 and the name 30 of the client 20 
realm) will desirably be presented in the BOOTP re- 
sponse to the client. The realm name 30 of the client 20 
in one implementation may be up to 128 bytes long, it 
further being preferred that the BOOTP response for 
the desired secure IPL include the realm name 30 of the 
client 20. 

A more detailed description will now be provided 
with reference to FIGS. 3 A and 3B of the formats of the 
Kerberos packets that should be understood by the 
BOOTP client 20. In a preferred implementation there 
are four basic packets 66 which are exchanged by the 
client 20 as follows: 

KRB_AS_REQ, 68, is a packet sent from the client 
20 to the Kerberos server 24 to obtain a ticket 48 to later 
present to the SECIPL service 28. 

KRB_AS— REP, 70, is a packet response from the 
Kerberos server 24 to the KRB— AS_REQ request in 
packet 68 and wiD contain the ticket 48 for the SECIPL 
service 28. 

KRB— AP_REQ, 72, is a packet sent from a particu- 
lar client 20 to the SECIPL service 28 to request an IPL 
kernel 70, which also contains the shared second key 71 
to be used for optional kernel encryption or crypto- 
graphic checksum. 

KRB_AP— REP, 74, is a packet containing a re- 
sponse from the SECIPL server 28 to the KRB-AP_ 
REQ request 72. There are provided in this packet the 
fields 75 and 73 which are part of the request packet and 
would preferably be encrypted, thereby requiring de- 
cryption by the client 20 utilizing the shared second key 
71 to authenticate the SECIPL server 28. 

The KRB_AS_REQ and KRB-AS_REP packets, 
68 and 70, respectively, will be sent as standalone pack- 
ets to and from the Kerberos server 24 identified in the 
BOOTP response 58. The KRB— AS--REP packet 70 
contents from the AS 24 will be checked with the first 
key 22 by client 20 to verify the Kerberos server or 24 
AS is a valid one. It should be apparent that only a valid 
Kerberos server 24 will contain the unique secret key 22 
of a particular client workstation 20. A ticket field 48 
from the KRB— AS_REP packet 70 will be placed in 
the KRB_AP— REQ packet 72 to present to the SE- 
CIPL server 28. The whole KRB^P_REQ packet 72 
will be preferably included in a TFTP RRQ packet 
directly behind the SECIPL option. (A modified 
TFTPB daemon is provided which will return a 
KRB— AP_REP packet 74 before starting the desired 
file transfer). 

Turning for a moment to a more detailed description 
of the SECIPL server 28, in a preferred implementation 
this SECIPL server 28 is a modified TFTPD server, 
such modification essentially being that the server sup- 
ports services for selection of IPL images based on 
supplied criteria from the client and that this modified 
server will return the KRB-AP_REP packet prior to 
beginning fde transfer to the client. The server 28 may 
preferably be included as part of the BOOTP server 44, 
or alternatively may be stand alone. The SECIPL 
server 28 will accept the hereinbefore described RRQ 
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packet along with information on the state of the key 
switch of the client, client processor type, main memory 
size, and the client's principal name 32. The server 26 
will then select a kernel based upon this information to 
return to the client 20. Tlie kernel data itself may desir- 5 
ably be encrypted with the shared session key 48 to be 
further described or the service may append a crypto- 
graphic checksum at the end of the kernel transfer. 

Still referring to FIGS. 3A and 3B, the KRB_AS— 
REP doubly-encrypted ticket will contain the ticket 10 
field 48 encrypted by the key Kl, reference numeral 22, 
as well as the key K2, 71, the first key 1 being known by 
the client and AS and key K2 being known by the AS 
and SECIPL. When the doubly encrypted ticket is 
received by the client 20, the principal name SECIPL 15 
and Kl may be stripped off leaving a four byte integer 
key on the client side. Similarly, the four byte integer 
key on the non client side encrypted with the K2 key 
may then be transmitted as the KRB_AP_REQ en- 
crypted packet to the SECIPL server. Because the K2 20 
key is known by the SECIPL server as well as the 
Kerberos server from which it originated in the 
KRB-^S-REP ticket, the SECIPL may strip this K2 
key off leaving the integer key known by both the chent 
and the SECIPL. As shown at the bottom of FIG. 3B, 25 
this four byte integer key may then be utilized to en- 
crypt the kernel 70 whereupon the encrypted kernel 

may be transmitted back to the client 20 as KRB— AP 

REP 74. Upon receipt by the client 20, this four byte 
integer key may be utilized by the client to decrypt the 30 
kernel 70 to provide the desired authenticated initial 
program load code. In the alternative, the kernel, upon 
transmission from the SECIPL, may be checksumed 
with the checksum encoded by the integer. Whereas 
this would permit reads of the kernel since it would be 35 
unencrypted when sent from the SECIPL to the client, 
the client could nevertheless by decrypting the check- 
simi transmitted from the SECIPL to the client, verify 
that although the kerne] may have been read by others 
it was not tampered with inasmuch as the checksum 40 
remained intact 

Further preferred details of implementation of the 
foregoing will now be described. One problem which is 
desired to be solved in any implementation of a secure 
boot of a diskless workstation is to provide an architec- 45 
ture whereby minimal modifications to existing systems 
may be made to provide this feature. A particularly 
desirable manner of implementing support for secure 
EPL in a diskless workstation in accordance with the 
invention is to provide a boot-time hook that searches 50 
I/O for IPL code. If such code is found, it is copied into 
real memory of the client and executed. The foregoing 
is a typical manner in which personal computers work 
for example. If the diskless machine or workstation does 
not have expansion slots allowing for additional I/O 55 
adapter devices, a preferred implementation would 
search the native I/O device space for a response to an 
IPL code-polling sequence. Devices which would give 
rise to such a response may include SCSI bus, serial, and 
parallel devices, for example. This form of secure IPL 60 
architecture accordingly allows the standard diskless 
workstation to be created with minimal modifications 
for secure IPL thereby providing numerous benefits 
relating to manufacturing and distribution. However, 
such architecture would moreover permit costs in- 65 
curred in developing such a secure IPL to be recovered 
only from customers requiring such a feature, e.g. when 
hardware is sold which includes the IPL code, encryp- 
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tion device, and removable key or keys, the customer 
would thereby be charged for the associated cost of 
level of security which might not be necessary for other 
customers. 

One problem associated with standard security ap- 
proaches such as a Kerberos system, is that in standard 
Kerberos technology a principal name is made up of 
two parts: the service name, and an "instance" name. 
The principal name 26 of the SECIPL service would 
accordingly be treated as a constant. There is no in- 
stance-specific component of the principal name. This 
further would normally be required because the client 
20, as previously described, must store the whole princi- 
pal name 26 of the SECIPL service 28 in ROM 42 or 
face possible security attacks such as those previously 
described. This, further, would imply that there is a 
single key which must be known by all instances of the 
SECIPL kernel server. This, in t\im, would imply that 
all machines and administrators that are able to service 
SECIPL requests must be as trusted as the Kerberos 
server machines 24 and administrators. The same level 
of physical security should therefore be maintained for 
the SECIPL service machine or machines 28 as for the 
Kerberos server machine(s) 24. 

In the embodiment previously described, m sum- 
mary, three keys were provided. First the secret key, 
used once, and known only to the client and authentica- 
tion server to the client and subsequently presented by 
the client to the SECIPL to obtain the boot image, and 
finally the shared key, K3, utilized for encryption or 
checksuming. 

It will be readily apparent that as described, the ser- 
vice key K2, assumes a previous communication be- 
tween the SECIPL and AS servers to agree on the 
service key, K2, to be distributed to clients. Moreover, 
the shared key K3, assumed such a key, perhaps created 
by the client, but nevertheless transmitted previously to 
the SECIPL server. In an alternate embodiment, a 
mechanism is provided to circumvent the intervention 
of a counterfeit server without a hardcoded name as 
previously described. Referring to FIG. 3, when the 
authentication server responds with the K2 ticket, 71, 
an additional step could be inserted which would cause 
the Kerberos server to send the K2 key to the SECIPL 
server (optionally encrypted with Kl). The client, 20, 
could then validate the SECIPL server as being genuine 
by requesting this K2 key from the SECIPL server. The 
client could thereafter decrypt the K2, K3 packet re- 
ceived from the Kerberos server utilizing the K2 key 
received from the SECIPl server and thereby validate 
the SECIPL server by looking for an identity between 
the remaining K3 key and the K3 key obtained by sim- 
ply decrypting with the Kl key. 

While the invention has been shown and described 
with reference to particular embodiments thereof, it 
will be understood by those skilled in the art that the 
foregoing and other changes in form and detail may be 
made therein without departing from the spirit and 
scope of the invention. 

We claim: 

1. A method executed by a computer system com- 
prised of a client and a server in a network for providing 
a secure operating system comprising 
storing a shared key at said client; 
communicating signals across said network compris- 
ing a request including said shared key from said 
client to said server interconnected by said net- 
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work for activating said operating system at said 
client; 

authenticating said request at said server; 

communicating signals across said network compris- 
ing a response from said server to said client in 5 
response to said authenticated said request, said 
response from said server including at least a por- 
tion of said operating system; 

authenticating said at least a portion of said operating 
system at said client with said shared key; and 1*^ 

activating said operating system at said client in re- 
sponse to said response from said server. 

2. The method of claim 1 wherein said authenticating 
said request is a precondition to said communicating 
said response. 15 

3. The method of claim 1 further including the step of 
authenticating at said client said response from said 
server. 

4. The method of claim 3 wherein said authenticating 
said response is a precondition to said activating said 
operating system. 

5. The method of claim 1 wherein said response from 
said server comprises said at least a portion of said oper- 
ating system encrypted prior to said communicating 
said response and decrypted prior to said activating said 
operating system. 

6. The method of claim 5 wherein said operating 
system is decrypted and encrypted by said client and . 
said server, respectively. 

7. The method of claim 1 wherein said response fur- 
ther comprises a cryptographic checksum of said at 
least a portion of said operating system verifiable by 
said client. 

8. A method executed by a computer system for pro- 35 
viding a secure operating environment at a client sta- 
tion, comprising 

storing a service key at a secure boot server; 
generating a request for a secure boot image from said 

client to a boot server; 4^ 
receiving a response from said boot server by said 

chent; 

comm\micating a request encoded by a key known by 
said client and an authentication server, corre- 
sponding in part to said boot server response, by 45 
said client to said authentication server for a token 
for said secure boot image comprised of at least 
said service key and a shared key; 

storing said shared key at said client; 

communicating said token from said authentication 50 
server to said client in response to said request; 

communicating said token from said cUent to said 
secure boot server; 

verifying said token with said service key at said 
secure boot server; 55 

communicating to said client from said secure boot 
server, in response to said verifying, at least a por- 
tion of an operating system authenticatable by said 
client with said shared key; 

authenticating said at last a portion of said operating 60 
system by said client with said shared key; and 

executing by said client said at least a portion of said 
operating system in response to said authenticating. 

9. The method of claim 8 wherein said response from 
said boot server includes an address of said boot server. 65 

10. The method to claim 9 wherein said response 
from said boot server further includes an address of said 
authentication server. 



,643 

10 

11. The method of claim 10 wheiem said request by 
said client to said authentication server includes a 
unique principal name of said boot server known to said 
client and to said authentication server and stored in 
non-volatile memory of said client. 

12. A method executed by a computer system includ- 
ing at least one client workstation interconnected to a 
network for providing an authenticated operating sys- 
tem at said client workstation comprising 

specifying a first key, a service key, and a shared key; 

transmitting onto said network a first request from 
said client workstation for an operating environ- 
ment; 

authenticating said first request received from said 
network with said first key; 

transmitting a token corresponding to said first key, 
said service key and said shared key onto said net- 
work, and to said client in response to said authen- 
ticating said receiving first request; 

transmitting onto said network a second request func- 
tionally related to said token from said client work- 
station for said operating environment; 

authenticating said second request received from said 
network with said service key; 

transmitting information at least partially encrypted 
with said shared key onto said network and to said 
client workstation in response to said authenticat- 
ing said received second request; 

decrypting said at least partiaDy encrypted informa- 
tion at said client with said shared key; and 

executing said operating environment at said client 
workstation in response to said decrypting of said 
at least partially encrypted information. 

13. The method of claim 12 wherein said authenticat- 
ing said received first request is by an authorization 
server attached to said network. 

14. The method of claim 13 wherein said token is 
transmitted from said authentication server. 

15. The method of claim 13 wherein said authenticat- 
ing said received second request is by a secure initial 
program load (SECIPL) server attached to said net- 
work. 

16. The method of claim 15 wherein said at least 
partially encrypted information is transmitted from said 
SECIPL server to said client workstation. 

17. The method of claim 16 wherein said at least 
partially encrypted information comprises at least part 
of an encrypted operating system decryptable by said 
chent workstation. 

18. The method of claim 16 wherein said at least 
partially encrypted information comprises a crypto- 
graphic checksum, decryptable by said client, of at least 
a part of an operating system transmitted from said 
SECIPL server to said client. 

19. A system for providmg a secure operating system 
for a client in a network environment, comprising 

authentication server means interconnected to said 
network for authenticating a request from said 
client for said operating system and providing to 
said client an indicator of authenticating; 

secure program load server means interconnected to 
said network for determming said client has re- 
ceived said indicator and transmitting encrypted 
data including at least a portion of an operating 
system on said network to said client in response to 
said determining; and said network to said client in 
response to said determining; and 
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client workstation means interconnected to said net- 
work for executing said secure operating system in 
response to unencrypting of said data by said client. 

20. The system of claim 19 wherein said client work- 
station means includes means for transmitting said re- ^ 
quest onto said network. 

21. The system of claim 20 wherein said client work- 
station means further includes means for receiving said 
indicator from said network. 

22. The system of claim 21 wherein said client means 
further mcludes means for transmitting on said network 
to said secure program load means information in re- 
sponse to said client workstation means receiving said 
indicator, from which said detemnining by said secure 15 
program load means is performed. 

23. The system of claim 19 wherein said encrypted 
data is a cryptographic checksum corresponding to said 
operating system. 
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24. A system for providing a secure operating system 
for a client in a network environment, comprising 

authentication server means interconnected to said 
network for authenticating a request from said 
cHent for said operating system and providing to 
said client an indicator of authenticating; 

secure program load server means interconnected to 
said network for determining said client has re- 
ceived said indicator and transmitting at least a 
portion of an operating system and a cryptographic 
checksum of said portion of said operating system 
on said network to said client in response to said 
determining; and 

client workstation means interconnected to said net- 
work for executing said secure operating system in 
response to authenticating said portion of said op- 
erating system with said cryptographic checksum 
by said client. 

***** 
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